home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 920 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.3 KB

  1. Path: cs.mu.OZ.AU!bounce-back
  2. From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Referencing pointers after delete
  5. Date: 01 Apr 96 04:11:21 GMT
  6. Organization: Comp Sci, University of Melbourne
  7. Approved: fjh@cs.mu.oz.au
  8. Message-ID: <4jmibl$qvt@mulga.cs.mu.OZ.AU>
  9. References: <m0u3D8A-000GcEC@7.kurahaupo.gen.nz>
  10. NNTP-Posting-Host: mundook.cs.mu.oz.au
  11. X-Original-Date: 31 Mar 1996 18:19:33 GMT
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMV9XsOEDnX0m9pzZAQGoIQGAi8mBx2KkWmTligRZVSt8Prq1Wh/5u2Pf
  14.     6/DQwo2MLKRq8rXHLgdXkE8J7Y2+EiFQ
  15.     =PLBm
  16. Originator: fjh@mundook.cs.mu.OZ.AU
  17.  
  18. martin@kcbbs.gen.nz (Martin D Kealey) writes:
  19.  
  20. [example implementation which can crash if a pointer is referenced
  21. after the memory it points to has been deleted]
  22.  
  23. >Is there anything in such an implementation that is unconforming?
  24. >If not, then I submit that "undefined behaviour" IS the correct
  25. >term to apply to *any* use of an invalidated pointer value.
  26.  
  27. I don't think there is any disagreement about whether it IS undefined
  28. behaviour; the question is about whether it should be.  Remember, every
  29. instance in which the standard leaves the behaviour undefined is one
  30. more hurdle for programmers trying to write portable programs.  I think
  31. the possible efficiency gains from allowing optimizations such as the
  32. one you described are likely to be very minimal even on those very rare
  33. systems on which they might apply.  If that were the only reason, I
  34. would think that it ought not be undefined behaviour.
  35.  
  36. However, the argument that the behaviour should be undefined in order
  37. to support implementations which perform pointer validity checking in
  38. hardware is more convincing.
  39.  
  40. --
  41. Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
  42. WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
  43. PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
  44. ---
  45. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  46. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  47. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  48. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  49. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  50.